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NETWORK  TREE  TECHNOLOGY:  AS  APPLIED  TO  DEVELOPMENT  OF 
FAULT  ISOLATION  PROCEDURES 


1.  SCOPE 

1.1  Background .  The  rising  cost  of  systems  maintenance,  the  need  for  a 
high  spares  inventory,  and  a  decrease  in  system  availability,  have  necessitated 
research  into  techniques  that  could  cost  effectively  produce  Fault  Isolation 
Procedures  (FIPs)  designed  to  combat  these  problems.  This  technical  paper 
details  the  results  of  the  study  effort,  performed  for  the  Air  Force  Human 
Resources  Laboratory  (AFHRL),  that  examined  the  use  of  network  tree  technology, 
and  its  associated  Sneak  Circuit  Analysis  (SCA)  data  base,  as  a  tool  for  the 
development  of  FIPs. 

In  1967,  Boeing  initiated  the  development  of  the  SCA  technique.  The  goal  of 
SCA  was  to  discover  basic  design  flaws  in  electrical  systems  without  regard  to 
system  failure.  This  technique  uncovers  paths  of  undesired  power/signal  flow 
(sneak  paths),  timing  problems  (sneak  timing),  and  false  or  misleading  system 
indications  and  nomenclature  (sneak  indications  and  sneak  labels).  The  SCA 
technique  has  been  modified  and  updated  continuously  since  its  inception  in 
order  to  keep  pace  with  advancing  electronic  technology.  In  its  present  form, 
it  is  highly  automated.  Analysts  take  detailed  system  schematics,  wire  lists, 
and  wiring  diagrams  and  enter  all  of  these  data  into  a  computer  data  base. 

Each  data  record  explicitly  describes  the  point-to-point  continuity  within  the 
system  being  analyzed.  After  a  series  of  audit  and  error  check  software  has 
screened  the  data  base,  a  series  of  reports  are  generated  and  translated  into 
tree  structured  images  (network  trees)  of  the  system's  circuitry.  Analysts 
then  apply  a  series  of  clues  (design  checks)  against  these  network  trees, 
depending  on  the  topology  of  the  trees,  in  an  effort  to  uncover  sneak 
circuits.  As  the  analysis  of  the  trees  progresses,  reports  are  generated 
which  describe  sneak  circuits,  design  concerns  (questionable  design 
practices),  and  document  errors.  New  capabilities  have  been  added  to  this 
technique,  including  the  analysis  of  software.  Compatibility  of  the  network 
tree  formats  provides  an  effective  tool  for  the  analysis  of  hardware/software 
Interaction,  as  well.  The  data  base  generated  for  a  SCA  also  supports  a 
variety  of  other  analyses,  such  as  Fault  Tree  Analysis  and  Failure  Modes  and 
Effects  Analysis. 

1.2  Goals  and  Objectives 

1.2.1  Investigate  the  application  of  network  tree  technology  for  use 
in  the  development  of  FjfrsJ  A  goal  of  this  study  was  to  determine  how  this 
data  base  and  the  resultant  network  trees  could  be  applied  to  the  development 
of  FIPs.  Sections  2  and  3  describe  how  the  data  base  and  network  trees  were 
successfully  applied. 

1.2.2  Develop  a  formal  methodology.  A  step-by-step  approach  should 
be  developed  for  applying  the  network  tree  technology  to  FIP  development;  this 
methodology  should  Include  data  base  construction,  manipulation,  and  network 
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tree  construction  and  application.  The  formal  methodology  developed  during 
this  Investigation  is  described  in  Section  4. 

1.2.3  Identify  areas  for  automation.  The  actual  system 
configuration  is  resident  in  a  computer,  which  can  be  a  powerful  tool  for 
automating  portions  of  the  FIP  development  process  and  can  improve  the  cost 
effectiveness  of  the  FIP  development  task.  The  goal  here  was  to  Identify 
those  areas  in  which  automation  could  be  applied.  The  areas  identified  for 
automation  are  included  in  the  formal  methodology  description  (Section  4). 

1.2.4  Provide  a  methodology  to  help  alleviate  current  maintenance 
problems.  A  major  goal  was  to  produce  FIPs  which  would  help  alleviate  such 
maintenance  problems  as  low  system  availability  and  high  maintenance  costs. 

In  order  to  do  so,  these  FIPs  must  minimize  fault  isolation  steps  required  to 
isolate  problems  to  the  Line  Replaceable  Unit  (LRU)  while  maximizing  the  use 
of  system  fault  indication  feedback.  The  FIPs  must  also  provide  the  user  with 
all  of  the  pertinent  information  required  to  do  the  job,  in  a  format  which  is 
readily  understood.  The  example  FIPs  given  in  Section  3  illustrate  the 
efficiency  of  the  procedures  developed  using  the  network  tree  approach  for 
both  line  and  shop  maintenance. 

1.3  Ground  Rules  and  Assumptions.  This  study  effort  was  conducted  using 
the  following  ground  rules  and  assumptions. 

1.3.1  F-16  Test  Case.  The  study  centered  its  system  analysis  phase 
on  the  F-16  aircraft.  Two  specific  test  cases  were  included  in  the  task  and 
were  specified  by  the  Headquarters,  Tactical  Air  Command.  The  hardware 
Involved  included  the  pitch  axis  lamp  and  the  servo/electronics  reset  switch 
and  the  circuitry  directly  related  to  these  two  components.  The  two  cases 
identified  were  as  follows: 

1.  Case  1:  Problem  -  The  F-16  is  airborne  when  the  pitch 
axis  lamp  Illuminates.  The  lamp  cannot  be  reset  in  flight. 

2.  Case  2:  Problem  -  the  F-16  is  on  the  runway  and  the  pitch 
axis  lamp  is  illuminated.  The  lamp  is  successfully  reset. 

No  other  malfunction  indications  had  been  defined. 

1.3.2  Use  existing  network  trees.  Network  trees  had  previously  been 
developed  .or  the  F-16  flight  Control  System  (FLCS)  and  the  Electrical  Power 
System  (EPS).  These  network  trees  were  to  be  used  as  the  source  of  systems 
data  for  this  study.  It  was  recognized  that: 

1.  The  existing  network  trees  might  not  totally  reflect  the 
present  system  configuration  due  to  modifications  made  to 
the  F-16  between  the  time  the  SCA  was  performed  (1978)  and 
the  initiation  of  this  effort  (May  1981). 

2.  The  network  trees  might  not  be  in  the  optimum  format  for 
this  task.  In  the  performance  of  SCA,  the  location  of 


electrical  components  is  not  relevant  to  the  analysis,  and 
as  such,  network  trees  are  constructed  to  illustrate  the 
system  circuitry  without  regard  to  physical  location. 

Wiring  data  and  connector  and  pin  data  are  suppressed.  It 
was  envisioned  that  these  data  should  not  be  suppressed 
for  FIP  development  and  also  that  the  construction  of  the 
network  trees  should  take  physical  location  into  account. 
All  the  encoded  information  would  be  available  for 
analysis,  however,  even  if  not  in  the  most  optimum  format. 

3.  All  of  the  required  data  might  not  be  available  in  network 
tree  format.  An  SCA  contract  can  be  scoped  to  include 
only  those  subsystems  as  selected  by  the  contracting 
agency.  In  the  F— 16  FLCS  SCA  task,  certain  modules,  such 
as  the  Air  Data  Computer,  were  intentionally  exempted  from 
analysis.  Should  any  of  this  information  be  required  for 
this  study  effort,  it  would  not  be  available  in  network 
tree  format,  and  this  fact  would  have  to  be  noted. 

1.3.3  Study  to  be  performed  manually.  The  study,  using  a  "paper 
data  base"  would  be  performed  manually,  with  no  additional  funding  available 
for  computer  support.  Areas  for  automation  would  be  identified  in  support  of 
future  activities. 

1.3.4  Fault  Isolation  Procedure  development  was  not  the  primary 
objective  of  this  study'.  The  development  of  the  methodology  of  applying 
network  tree  technology  to  FIP  development  was  as  important,  if  not  more  so, 
than  the  development  of  the  actual  procedures  for  the  stated  test  cases.  Any 
procedures  developed  under  this  contract,  however,  should  reflect  the  benefit 
of  the  approach.  These  procedures  did  not  have  to  comply  with  current 
military  standards  and  specifications  for  FIPs. 

2.  STUDY  EFFORT  SUMMARY 

This  section  of  the  technical  paper  summarizes  the  study  effort  activities. 

Its  purpose  is  to  define  the  flow  and  accomplishments  of  this  study  along  with 
the  points  of  caution  recognized  along  the  way.  There  are  some  major  points 
of  departure  between  this  study  effort  and  the  actual  methodology  required  to 
develop  FIPs,  based  on  network  trees,  and  these  points  are  also  discussed  here. 

2.1  Network  Tree  Sorting 

There  were  1,980  existing  F-16  network  trees  for  the  FLCS  and  the  EPS  (about 
2,500  pages).  Not  all  of  these  network  trees  were  required  by  this  study 
effort,  and  so  this  paper  data  base  had  to  be  sorted  in  order  to  extract  those 
network  trees  which  were  applicable.  This  initial  sorting  activity,  performed 
manually,  resulted  in  the  extraction  of  613  network  trees. 

This  sorting  activity  is  the  first  point  of  departure  from  the  FIP  development 
methodology  described  in  Section  4.  The  formal  methodology  requires  that  the 
system  data  be  resident  in  the  computer  in  the  data  record  format  previously 


described.  Since  this  study  was  performed  using  a  paper  data  base  (reference 
Section  1.3.2),  the  sorting  activity  required  may  not  be  necessary  (at  least 
to  this  extent)  when  using  a  computer-supported  data  base. 

2.2  Forest  Development 

The  next  step  in  the  study  was  to  develop  forests  from  the  network  trees 
extracted  during  the  first  study  phase.  Sixty-three  forests  were  developed  in 
the  time  available  for  this  activity. 

It  became  evident  that  forest  development  would  be  much  more  cost  effective 
when  performed  using  a  computer  supported  data  base.  Manual  forest 
development  from  existing  network  trees,  therefore,  represents  another 
departure  from  the  FIP  development  methodology  given  in  Section  4.  In 
essence,  an  active  SCA  data  base  should  be  used  to  dynamically  create  forests 
and  network  trees  in  the  same  time  frame,  rather  than  working  back  from 
existing  network  trees. 

This  forest  development  activity  also  pointed  out  the  need  for  partitioning 
the  data  base  in  support  of  specific  FIP  development  requirements.  This  is 
discussed  in  Section  4. 

2.3  Test  Case  Analysis 

The  test  case  conditions  (reference  Section  1.3.1)  required  that  the  circuitry 
associated  with  the  pitch  axis  lamp  and  the  servo/electronics  reset  switch  be 
analyzed.  The  reset  function  and  the  signals  which  cause  the  pitch  lamp  to 
illuminate  had  to  be  studied  in  order  to  assess  how  they  interact.  Reset 
signal  distribution  and  application  were  analyzed.  Analysis  was  required  to 
determine  if  the  reset  signal  could  be  interrupted  due  to  system  design,  and 
if  so,  under  what  conditions  this  could  occur. 

The  reset  signals  that  were  studied  were  generated  when  the  servo/electronics 
reset  switch  on  the  Flight  Control  Panel  (FLCP)  was  placed  (momentarily)  to 
the  ELEC  position.  Figure  1  illustrates  a  portion  of  the  network  tree  which 
shows  this  reset  signal  distribution. 

The  two  signals  of  Interest  were  the  ELEC  RESET  signal  and  the  SELECT  RESET 
signal.  Although  both  signals  emanate  from  the  same  source,  the  SELECT  RESET 
signal  path  contains  a  (normally  closed)  relay  that  would  serve  to  interrupt 
this  signal  under  certain  conditions.  Before  investigating  these  conditions, 
however,  the  distribution  of  both  these  signals  had  to  be  traced  in  order  to 
analyze  how  they  are  applied  to  the  flight  control  circuitry.  In  order  to  do 
this,  two  forests  were  developed  which  showed  the  reset  signal  distributions. 
These  forests  are  illustrated  in  Figure  2.  The  SELECT  RESET  signal,  it  turned 
out,  was  applied  to  the  same  network  trees  as  the  ELEC  RESET  signal  with  only 
five  exceptions  to  which  ELEC  RESET  was  not  applied.  These  exceptions  were 
two  network  trees  which  dealt  with  the  left  and  right  flaperon  logic:  one 
which  dealt  with  the  rudder,  and  two  which  involved  the  left  and  right 
horizontal  tail.  Since  the  left  and  right  horizontal  tail  circuitry  can  cause 
the  pitch  light  to  illuminate,  these  relations  were  studied  further. 
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Figure  2.  "ELEC"  and  "SELECT"  Reset  Signal  Distribution  Forest 


It  could  not  be  assumed,  in  those  cases  where  the  SELECT  RESET  and  ELEC  RESET 
were  applied  to  the  same  network  tree,  that  they  were  applied  in  the  same 
manner  or  even  to  the  same  circuitry.  A  quick  study  of  the  network  trees 
involved,  however,  showed  that  these  signals  were  applied  to  the  same  point 
(Figure  3).  A  loss  of  the  SELECT  RESET  signal  to  these  points  would  not 
result  in  the  loss  of  the  reset  function. 


SELECT 

RESET 


PITCH  CMP  BRANCH  A.  FAIL  AND  RESET  (N.S.  UPS) 


Figure  3.  ELEC  and  SELECT  RESET  Signal  Common  Point 
Application  Example. 


Top  level  functional  forests  were  developed  for  the  pitch  lamp  drive  circuitry 
and  the  select  reset  function.  Figure  4  is  the  example  for  the  left 
horizontal  tail  (LHT),  and  shows  that  a  loss  of  the  SELECT  RESET  signal  could 
result  in  the  inability  to  reset  the  pitch  axis  lamp.  A  similar  forest  exists 
for  the  right  horizontal  tail. 

The  network  trees  were  then  examined  in  order  to  determine  the  conditions 
under  which  the  SELECT  RESET  signal  would  normally  be  interrupted. 

As  can  be  seen  in  Figure  5,  two  conditions  must  exist  in  order  to  interrupt 
the  SELECT  RESET  signal  (other  than  a  signal  path  discontinuity).  A  dual 
failure  condition  (FC)  must  exist  and  the  aircraft  must  be  airborne.  Other 
failure  Indications  would  also  be  present,  although  they  were  not  defined  in 
the  orglnal  test  case  description.  The  Dual  FC  Fall  warning  lamp,  for 
example,  should  also  light  under  these  conditions. 
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Figure  4.  LHT  Servo  Actuator /Select  Reset  Forest. 


Since  a  dual  alpha  fall  (high)  signal  can  also  result  In  the  opening  of  the 
select  reset  signal  relay,  the  angle-of -attack  (AOA)  circuitry  was  also 
analyzed  by  the  generation  of  AOA  signal  forests.  During  this  analysis,  it 
was  noted  that  signals  from  Channel  A  of  both  AOA  sensors  were  fed  into  the 
Air  Data  Computer.  Since  the  Air  Data  Computer  had  not  been  Included  in  the 
original  SCA  Statement  of  Work,  there  were  no  network  trees  available  to 
continue  this  line  of  investigation. 

This  lack  of  data  underscores  a  highly  important  point:  all  of  the  hardware 
In  a  system  must  be  encoded  and  analyzed  If  effective  FIPs  are  to  be 
developed.  Missing  data  could  result  In  inadequate  procedures  because  all  of 
the  possible  cause  and  effect  relationships  cannot  be  fully  defined.  Vital 
fault  Indications  could  also  go  unrecognized,  and  It  Is  a  goal  of  network  tree 
supported  FIPs,  to  take  full  advantage  of  all  available  clues  and  indications 
In  the  fault  Isolation  process. 


c.  Case  2  (pitch  light  resets  when  the  aircraft  is  on  the  ground)  is  a 
subset  of  Case  1  (pitch  light  cannot  be  reset  while  airborne)  and 
also  reflects  system  operation  as  designed. 

3.  FAULT  ISOLATION  PROCEDURE  DEVELOPMENT 

3.1  Top  Level  Logic.  Effective  FIPs  will  take  advantage  of  all  possible 
system  clues  in  guiding  the  users  to  the  appropriate  test  procedures. 

Multiple  fault  Indications  can  also  provide  excellent  pointers  to  specific 
system  problems.  At  the  top  level,  the  goal  is  to  present  enough  fault 
indication  Information  to  guide  the  user  to  the  appropriate  procedural  group 
(in  this  case,  pitch  axis  related  failures).  No  testing  should  be  required  at 
this  level.  A  partial  top  level  logic  diagram,  the  FLCS  FAULT  ISOLATION 
ROADMAP,  is  illustrated  in  Figure  6.  It  should  be  noted  here  that  the 
"condition"  column  is  not  limited  to  physical  fault  indication  clues.  Sensory 
feedback,  in  this  case  to  the  pilot,  can  also  be  Included  in  this  column.  In 
this  example,  the  roadmap  was  not  continued  beyond  the  point  where  the  next 
logic  level  (PITCH  AXIS  ROADMAP)  was  selected. 


case  analysis.  When  structured  to  involve  all  of  the  possible  conditions  and 
fault  indications  which  relate  to  the  pitch  axis,  this  logic  could  be  quite 
different. 

In  order  to  test  the  value  of  network  tree  technology  in  this  FIP  development 
activity,  conditions  were  selected  in  which  the  system  was  not  responding  as 
designed.  For  this  case,  the  pitch  axis  lamp  could  not  be  reset  after 
landing,  and  procedures  were  developed  to  determine  why  this  condition  existed 


3.3  FIP  DEVELOPMENT  (LRU  Level).  The  next  objective  was  to  isolate  the 
problem  (pitch  lamp  falls  to  reset  under  all  conditions)  to  the  faulty  LRU. 

In  order  to  do  so,  a  functional  forest  was  developed  for  the  pitch  lamp  and 
reset  circuitry.  This  forest  was  also  labeled  with  the  appropriate  connector, 
pin,  and  wiring  data.  This  forest  Is  Illustrated  In  Figure  8.  Using  this 
forest,  a  set  of  FIPs  was  developed  which  used  a  combination  of  testing  and 
observations  to  Isolate  the  faulty  LRU  wiring.  The  voltage  levels  denoted  in 
the  procedures  designed  from  Figure  11  do  not  reflect  any  tolerances. 

The  following  steps  represent  one  of  the  possible  paths  of  this  procedure 
(Illustrated  In  Figures  9,  10,  and  11): 

Step  1  -  The  user  observes  the  reaction  of  the  pitch  axis  lamp  as  the 
servo/electronics  reset  switch  Is  positioned  to  the  ELEC  position.  In 
this  case,  the  pitch  lamp  is  not  affected,  and  the  user  proceeds  to  step  2. 

Step  2  -  The  user  measures  the  voltage  between  aircraft  ground  and  Flight 
Control  Computer  (FLCC)  connector  2712P108,  pin  111.  In  this  case  the 
voltage  measures  28V0C,  Indicating  that  the  main  landing  gear  weight  on 
wheels  circuitry  (relay  B)  Is  functioning  correctly.  The  user  proceeds  to 
step  8. 

Step  8  -  The  user  measures  the  voltage  between  FLCC  connector  2714P111, 
pin  69  and  aircraft  ground,  while  the  servo/electronics  reset  switch  Is 
held  in  the  ELEC  position.  In  this  case,  the  voltage  is  28VDC,  Indicating 
that  the  reset  signal  is  being  transmitted  to  the  FLCC  successfully.  The 
user  then  proceeds  to  Step  11. 

Step  11  -  The  user  now  disconnects  FLCC  connector  P107  and  observes  the 
pitch  lamp.  In  this  case  the  pitch  lamp  went  off,  indicating  that  the 
lamp  has  not  been  shorted  to  ground  outside  of  the  FLCC,  and  that  the 
cause  of  the  problem  lies  within  the  FLCC. 

In  this  example,  two  observations  and  two  tests  (four  steps)  were  required  to 
Isolate  the  FLCC.  The  maximum  number  of  steps  which  might  be  performed  In 
this  procedure  Is  six.  This  Is  the  case  where  the  pitch  lamp  Is  being  shorted 
to  ground  In  the  wiring  between  the  FLCC  and  the  FLCP. 

3.4  FIP  Development  (Internal  to  an  LRU).  The  previous  set  of  procedures 
allowed  the  user*  to  Isolate  the  FLCC  as  the  faulty  LRU  with  only  four  steps. 
Replacing  that  FLCC  would  make  the  aircraft  operational  again,  with  no 
additional  equipment  changeout  other  than  the  faulty  LRU.  The  problem  now  Is 
to  determine,  again  as  rapidly  as  possible,  where  the  problem  lies  within  the 
faulty  LRU.  To  do  this,  a  more  detailed  forest  of  the  applicable  circuitry 
within  the  FLCC  was  generated.  This  forest  Is  Illustrated  In  Figure  12. 

This  forest  was  generated  to  the  card  level.  Each  card  Is  treated  as  a 
separate  "box,"  and  the  Interconnections  between  these  cards  are  Illustrated, 
along  with  the  voltage  levels  or  signal  values  at  the  appropriate  points.  The 
network  trees  used  to  develop  this  forest  did  not  contain  the  connector  or  pin 
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Figure  8.  Functional  Forest  for  Pitch  Lamp  and  Reset 
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CONDITION:  PITCH  LAMP  IS  ILLUMINATED;  CANNOT  SB  RESET  ON  THE  GROUND 1 
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RESET  FUNCTION  AND  MAIN  LANDING 
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CONDITION:  PITCH  LAMP  IS  ILLUMINATED;  CANNOT  BE  RESET  ON  THE  GROUND 
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Figure  10,  Pitch  Axis  Fault  Isolation  Procedure  2740-A1,  Page  2 


=7V1  4  *  "4  * .  »**.**.*•  *  *  *  * 


CONDITION:  PITCH  LAMP  IS  ILLUMINATCD;  CANNOT  BE  RESET  ON  TKC  CROUNO 
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Figure  11.  Pitch  Axis  Fault  Isolation  Procedure  2740-A1,  Page  3 


Figure  12.  FLCC  Internal  Pitch  Lamp  Drive/Reset  Forest. 


information  at  this  level.  Network  trees  created  for  FIP  development,  of 
course,  would  have  this  information. 

This  forest  can  then  be  used  to  fault  isolate  to  the  card  level.  As  an 
example,  if  28V0C  is  applied  to  PT 1 1/69  and  a  measurement  is  taken  between 
ground  and  pins  2,  3,  a  <d  4  (arbitrarily  assigned)  on  card  2711A5A7,  all  three 
measurements  should  be  28V0C.  If  all  three  measure  0  volts,  a  measurement 
should  be  taken  at  pin  1  of  the  same  card  to  determine  if  28VDC  is  being 
applied  there.  If  so,  then  the  select  reset  relay  or  the  path  between  pin  1 
and  the  relay  should  be  examined  to  determine  the  problem.  This  can  be  done 
by  generating  a  forest  of  the  appropriate  circuitry  on  card  2711A5A7  and 
building  procedures  from  that  forest.  The  time  available  for  this  study  did 
not  allow  for  the  development  of  forests  and  procedures  beyond  this  level  of 
detail. 
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4.  FIP  DEVELOPMENT  METHODOLOGY 


The  following  paragraphs  define  the  methodology  for  generating  FIPs  using 
network  tree  technology.  This  methodology  is  based  on  the  lessons  learned 
during  this  study  contract  and  includes  those  areas  of  automation  which  have 
been  determined  to  be  relatively  simple  to  implement  as  well  as  highly  cost 
effective. 

4.1  Data  Base  Development 

4.1.1  Data  Requirements.  The  hardware  data  required  for  FIP 
development  are  the  same  as  thFTata  required  to  perform  SCA  and  include 
integrated  and  detailed  schematics,  wire  lists,  wiring  diagrams,  and  unique 
component  specifications.  In  addition,  system  operating  instructions,  system 
descriptive  data,  and  system  specifications  and  design  criteria  are  required 
(as  available) . 

It  is  important  to  note  that  all  system  hardware  data  must  be  included. 
Subsystems  cannot  be  selectively  excluded  from  the  analysis  since  all 
cause-and-effect  relationships  must  be  thoroughly  investigated. 

If  the  system  being  analyzed  uses  software  in  the  control  and/or  monitoring  of 
its  activities,  sufficient  data  pertaining  to  the  purpose,  function,  and 
design  of  this  software  must  also  be  supplied.  Although  it  is  not  mandatory 
to  perform  a  software  analysis,  the  role  of  the  software  must  be  understood. 
This  is  especially  true,  in  those  cases  where  fault  indications  can  be 
software  driven. 

When  possible,  systems  operation  data  must  be  supplied  that  allow  a  complete 
understanding  of  the  modes  of  operation  and  the  system's  configuration  during 
these  operational  modes.  This  information  is  required  in  order  to  relate  the 
system  configuration  to  the  possible  fault  indications  as  a  function  of  the 
mode  of  operation. 

4.1.2  Data  Entry  Process.  The  electrical  configuration  data  are 
entered  into  the  computer  using  an  interactive  data  entry  process  which  helps 
structure  the  data  as  80  character  pseudo  card  images  as  described  in  Section 
5.  Error  checking  software  and  a  rigid  quality  control  program  are  required 
to  ensure  data  accuracy  and  completeness. 

Each  data  record  must  contain  at  least  the  following  information. 

1.  “From"  Point:  Location  of  the  node  (LRU,  Card,  etc.),  the  component 
type  (resistor,  switch,  relay,  etc.),  and  the  appropriate  pin  number 
(as  required). 

2.  "To"  Point:  Same  as  for  the  "From"  Point. 

3.  Diode  indicator  to  show  current  flow. 
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4.  Remarks  field  to  highlight  special  information  such  as  signal  type, 
power  level,  key  element  notations  (reference  Section  5.8),  key 
element  names,  connector  and  pin  terminology,  and  wire  bundle 
nomenclature. 

These  data  can  be  entered  in  any  format  that  is  compatible  with  the  user's 
downstream  software  programs.  The  format  described  here  reflects  the 
structure  required  for  compatibility  with  the  Boeing  family  of  SCA  programs. 

The  data  base  must  then  be  analyzed  to  determine  whether  there  are  any  open 
ends  and,  if  so,  whether  those  open  ends  are  valid.  Most  of  this  task  should 
be  automatic  by  use  of  audit  and  edit  programs. 

4.1.3  Change  Tracking.  Whenever  system  changes  are  implemented, 
these  changes  must  be  reflected  in  the  data  base.  Changes  to  the  system 
baseline  are  made  interactively,  and  the  network  trees  are  also  modified. 

Small  changes  may  require  only  manual  tree  modifications.  Large  changes  and 

some  basic  design  changes  may  require  that  the  appropriate  network  trees  and 

forests  be  redrawn. 

In  certain  cases,  a  system  is  designed  so  that  it  may  exist  in  several  basic 
configurations.  In  these  cases,  a  baseline  configuration  data  base  can  be 
developed,  along  with  a  separate  "Delta"  data  base  for  each  unique 
configuration.  This  approach  also  is  useful  when  analyzing  a  system  that 
interfaces  with  a  variety  of  "Add  On"  components.  Whether  the  data  base  is 

designed  as  a  single  data  base  or  a  baseline  with  "Deltas,"  it  cannot  be 

overemphasized  that  changes  to  the  system  must  be  tracked  and  reflected  in  the 
data  base,  and  implementation  of  changes  must  be  done  throughout  the  system's 
life  cycle  to  ensure  that  the  resulting  FIPs  retain  their  accuracy. 

4.2  Forest  and  Network  Tree  Development 

4.2.1  Data  Base  Sorting.  For  each  key  element,  a  search  is 
initiated  to  create  a  sub-data  base  which  contains  all  data  records  that  lead 
to  and  from  the  specific  key  element.  Data  records  used  in  more  than  one 
sub-data  base  are  keyed  to  indicate  this  multiple  usage.  Each  sub-data  base 
is  then  sorted  by  its  reference  designator  (REFDES)  in  order  to  separate  the 
data  records  into  their  physical  locations  (LRU,  Card,  etc.).  As  long  as  each 
key  element  has  been  flagged  in  the  data  base,  and  the  REFDES  of  each  data 
record  has  been  properly  assigned,  then  this  entire  sorting  process  can  be 
performed  automatically. 

4.2.2  Forest  and  Tree  Plotting.  Once  the  sorting  process  has  been 
completed,  forest  and  network  tree  construction  may  begin.  For  each  key 
element,  reports  are  developed  that  define  all  of  the  LRU-to-LRU  interfaces, 
the  LRU-to-Card  Interfaces,  the  Card-to-Card  Interfaces,  etc. 


Assuming  that  the  appropriate  pin,  connector,  wire  number,  and  signal  value/ 
power  level  information  has  been  encoded  in  the  data  records,  these  reports 
will  provide  all  of  the  system  data  required  to  construct  the  forests  and 


network  trees  used  In  the  FIPs  development  process.  Ideally,  these  forests 
and  network  trees  should  be  created  directly  from  these  reports  and  be 
automatically  plotted  and  annotated.  Interactive  user  intervention  should 
also  be  available  to  allow  forest  and  network  tree  restructuring  required  for 
analysis  and/or  documentation  purposes. 

It  is  not  mandatory  that  this  plotting  and  annotation  activity  be  fully 
automated.  If  this  activity  is  performed  manually,  however,  it  is  vital  that 
the  reports  used  to  create  these  plots  contain  all  the  vital  information  (as 
described  in  Section  4.1.2). 

4.3  Key  Element  Analysis 

4.3.1  Fault  Indicator  Analysis.  The  forests  and  network  trees  for 
each  fault  indicator  must  be  thoroughly  analyzed  to  determine  all  the 
conditions  which  will  drive  the  fault  indicator.  In  addition,  each  fault 
indication  must  be  classified  as  to  whether  it  reflects  a  normal  or  an 
abnormal  system  response  to  a  given  set  of  conditions.  All  conditions,  under 
which  two  or  more  fault  indications  are  generated,  must  be  defined.  This 
fault/response  information  is  vital  to  ensuring  that  maximum  use  of  available 
fault  clues  is  made.  As  the  use  of  available  fault  clues  is  increased,  the 
requirements  for  testing  hardware  are  decreased.  This  is  especially  true  of 
testing  to  the  LRU  level,  although  it  can  be  shown  to  be  true  to  even  greater 
levels  of  detail. 

4.3.2  Input  Element  Analysis.  The  forests  and  network  trees  for 
each  key  element  tnat  provides  an  input  to  the  system  (switches,  sensors, 
etc.)  or  that  changes  the  electrical  configuration  of  the  system  must  be 
thoroughly  analyzed  to  determine  all  normal  and  abnormal  system  responses 
(including  lack  of  response)  to  these  inputs.  Each  abnormal  response  is  also 
a  valid  fault  indication  and  Is  added  to  the  list  of  fault  indications  along 
with  the  conditions  under  which  each  abnormal  response  can  occur. 

4.3.3  Systems  Operation  Analysis.  Additional  fault  indications  may 
be  determined  through  the  analysis  of  the  system  operation.  Network  tree 
technology  does  not  play  an  active  role  in  this  analysis,  although  it  will 
play  an  Important  role  later  on,  when  the  FIPs  are  developed  for  these  fault 
indications. 

4.4  Logic  Diagram  Development 

4.4.1  Forest  Modification.  For  each  fault  indication,  the 
associated  forests  and  network  trees  are  analyzed  to  isolate  the  possible 
conditions  which  could  stimulate  that  Indication.  In  some  cases,  several 
forests  (or  portions  of  forests)  must  be  combined  to  yield  a  more  effective 
fault  Isolation  tool.  All  data  which  do  not  relate  to  the  fault  Indication 
being  studied  are  eliminated  from  the  modified  forest.  Since  the  Initial  goal 
is  to  isolate  the  fault  to  the  LRU  level,  the  modified  forest  does  not  include 
any  more  data  than  required  for  LRU  isolation.  When  the  goal  is  to  isolate 
faults  within  all  LRUs,  the  data  Included  In  the  forest  Increase  in  detail, 
and  extraneous  data  are  eliminated. 
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Regardless  of  the  level  of  detail  of  the  forests,  the  goal  is  the  same:  To 
provide  a  clear  picture  of  the  circuitry  involved  with  the  fault  indication, 
in  a  format  which  is  readily  usable  in  the  development  of  testing  logic 
diagrams. 


4.4.2  Testing  Logic  Development.  The  modified  forests  are  now  in  a 
condition  that  will  allow  easy  determination  of  which  pins  and/or  connectors 
should  be  tested,  the  correct  voltage  levels  at  those  pins  and/or  connectors, 
and  the  conditions  under  which  the  correct  voltage  levels  will  and  will  not 
exist.  Generating  the  testing  logic  is  not  a  simple  translation  of  the  forest 
into  a  set  of  tests  and  observations,  however.  It  accomplishes  nothing  to 
develop  FIPs  which  minimize  the  number  of  tests  performed,  if  the  maintenance 
workload  required  to  perform  those  tests  is  inordinately  increased. 

Therefore,  the  testing  logic  diagrams  must  be  developed  not  only  through  the 
use  of  the  modified  forests,  but  through  the  application  of  common  sense, 
systems  knowledge,  and  an  awareness  of  the  techniques  and  problems  of  the 
maintenance  function. 

The  testing  logic  begins  either  at  the  LRU,  where  the  majority  of  the  tests 
can  be  performed,  or  at  a  location  that  will  eliminate  a  large  segment  of  the 
suspect  circuitry. 

Each  subsequent  test  should  then  eliminate  up  to  half  of  the  remaining 
circuitry,  until  the  fault  is  successfully  isolated.  In  some  cases,  the 
suspect  circuitry  can  be  blocked  into  functional  groups,  and  each  test  should 
be  calculated  either  to  eliminate  or  to  fault  isolate  a  specific  circuitry 
group.  This  approach  is  highly  beneficial  when  additional  clues  and  visual 
observations  might  be  available  to  help  the  fault  isolation  process.  Consider 
the  FIP  illustrated  In  Figures  9,  10,  and  11.  If  another  axis  lamp  been 
illuminated  (roll,  for  example)  and  that  lamp  successfully  reset,  then  the 
user  could  safely  proceed,  beginning  at  step  11  of  the  procedure,  and  isolate 
the  fault  within  three  steps. 

Once  the  fault  has  been  isolated  to  the  LRU,  it  is  important  that  all  the 
knowledge  gained  during  this  isolation  process  be  passed  on  to  the  personnel 
that  will  perform  the  LRU-internal  fault  isolation.  This  can  be  accomplished 
readily  by  denoting  the  title  of  the  appropriate  LRU-internal  FIP  to  be 
followed,  directly  on  the  LRU  FIP  at  the  step  where  the  fault  isolation  is 
accomplished.  In  this  way,  shop  maintenance  can  be  initiated  at  the  correct 
point  in  the  fault  isolation  process,  thereby  greatly  increasing  the 
effectiveness  of  the  total  maintenance  function. 

By  using  the  network  trees  and  forests,  FIPs  can  be  developed  to  isolate  a 
faulty  LRU  and  then  direct  the  user  to  the  correct  procedure  set  required  to 
fault  isolate  the  card  and/or  component,  as  applicable.  Therefore,  both  line 
maintenance  and  shop  maintenance  procedures  are  developed  together,  in 
harmony,  rather  than  as  two  separate,  hard-to-relate  entitles. 
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5.  CONCLUSIONS 


5.1  Study  Results 

The  technique  of  developing  FIPs  using  network  tree  technology  has  the 
potential  to  be  highly  effective.  The  current  data  structure  used  for  SCA  Is 
well  suited  for  the  searching,  partitioning,  and  sorting  required  by  this  FIP 
development  methodology.  The  automation  of  this  searching,  partitioning,  and 
sorting  does  not  appear  to  be  a  difficult  task  and  would  highly  Increase  the 
productivity  of  the  technique.  The  plotting  of  network  trees  and  forests  can 
be  performed  manually,  although  automated  plotting  (with  Interactive  user 
Intervention  capability)  Is  the  preferable  approach.  Research  and  development 
activities  are  In  progess  to  develop  this  capability. 

Analysis  of  the  resulting  network  trees  and  forests,  and  the  translation  of 
that  Information  Into  effective  FIPs,  Is  still  a  manual  process  requiring 
skilled  personnel.  A  great  advantage  to  the  use  of  forests  and  network  trees, 
however.  Is  the  capability  to  create  both  line  and  shop  maintenance  procedures 
In  which  the  continuity  of  the  fault  Isolation  process  is  maintained.  This 
continuity  between  line  and  shop  maintenance  procedures  should  dramatically 
Increase  the  effectiveness  of  the  maintenance  function. 

Because  the  configuration  of  the  system  Is  contained  In  a  computer  data  base, 
system  changes  can  readily  be  reflected  In  that  data  base.  The  addition  of 
peripheral  devices  to  the  system  can  also  be  easily  accommodated.  The  system 
changes  and  additions  can  then  be  evaluated  for  Impact  on  the  FIPs  (as  well  as 
system  operations).  The  data  base,  therefore,  becomes  an  important  tool  to  be 
used  In  combatting  maintenance  problems  that  are  generated  by  production  phase 
and  post-production  phase  system  modifications. 

5.2  Cautions 

The  success  of  this  technique  Is  highly  dependent  on  the  quality  and  content 
of  the  data  base  being  used.  This  data  base  must  contain  every  link  In  the 
system's  electrical  continuity.  Each  data  record  must  describe  a  single 
point-to-point  path.  All  system  components  must  be  Included.  Precise  system 
nomenclature  must  be  used.  The  reference  designators  must  be  accurately 
defined  so  that  both  the  function  and  physical  location  of  the  circuitry  can 
be  Identified. 

The  accuracy  of  the  data  base  Is  dependent  on  the  accuracy  of  the  detailed 
schematics  and  other  data  required  to  build  It.  Changes  must  be  incorporated 
as  soon  as  possible.  Drawing  errors  must  be  eliminated  so  that  they  do  not 
Influence  the  final  data  base. 

The  automated  pathlng,  described  In  Section  4.2,  cannot  be  performed  without 
user  Intervention  In  some  cases.  Certain  digital  logic  devices,  and  the  use 
of  software  or  firmware  to  perform  systems  functions,  make  end-to-end  pathlng 
currently  Impossible  without  an  Intervening  analysis  of  the  functions  and 
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drivers  of  these  devices.  Present  techniques  will  allow  automated  pathlng  up 
to,  and  away  from,  these  devices.  A  trained  analyst  Is  required  to  provide 
the  remaining  links.  It  is  envisioned  that  this  problem  can  be  partially 
alleviated  by  a  "library"  of  component  types  and  uses.  The  use  of  software 
network  trees  to  provide  the  required  hardware/software/hardware  linkages  is 
also  a  prime  candidate  for  investigation. 

It  should  be  noted  that  the  approach  used  in  this  study,  and  the  resultant 
technique  and  areas  for  automation,  were  based  on  the  use  of  a  data  base  as 
defined  by  the  Boeing  SCA  requirements.  Similar  type  data  bases  can  be  used, 
providing  they  contain  all  of  the  data  described  in  the  previous  paragraphs. 

5.3  Technique  Application 

The  technique  defined  by  this  study  provides  the  tools  required  to  develop 
FIPs  in  the  form  of  network  trees  and  forests.  These  tools  can  be  used  in  the 
Logistics  Support  Analysis  program  to  develop  the  actual  fault  isolation 
logic.  Once  developed,  this  logic  would  be  formatted  into  document  quality 
procedures  by  technical  writing  and  documentation  personnel. 


APPENDIX  A 


DEFINITIONS  OF  KEY  TERMS 


The  following  are  the  key  terms  and  definitions  used  throughout  this  Technical 
Report . 

Data  Record .  The  system  configuration  data  required  In  the  performance  of 
Sneak  Circuit  Analysis  (SCA)  is  entered  Into  a  computer  In  the  form  of  data 
records.  Each  data  record  (as  Input)  Is  80  characters  In  length  and  has  the 
generic  structure  shown  In  figure  A-1. 
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Figure  A-1.  Structure  of  an  SCA  Data  Record 


These  data  records  are  then  searched  and  sorted  by  a  variety  of  SCA 
appl Icatlons  programs  In  order  to  produce  the  network  trees  required  to 
perform  SCA. 

Nodal  Set.  One  output  of  the  SCA  family  of  programs  Is  a  report  that  contains 
groups  of  specific  data  records  describing  the  circuitry  which  are 
functionally  and  physically  linked.  Each  of  these  groups  Is  called  a  nodal 
set  and  Is  given  a  unique  number  for  future  cross-reference. 

Network  Tree.  The  data  In  each  nodal  set  report  are  then  transferred  to  a 
topological  plot  of  circuitry.  Each  of  these  annotated  plots  of  the  system 
circuitry  Is  called  a  network  tree.  These  network  trees  are  then  used 
directly  In  the  performance  of  SCA.  A  typical  network  tree  Is  Illustrated  In 
Figure  A-2. 

Forest.  A  forest  Is  a  plot  of  related  network  trees  which  provides  a  broader 
view  of  the  physical  and  functional  system  continuities.  Forests  are 
constructed  In  various  levels  of  detail  in  order  to  support  both  system 
operational  analysis  and  the  development  of  FIP  logic  diagrams.  A  high  forest 
Is  illustrated  In  Figure  A-3. 


Power  Forest.  A  power  forest  traces  electrical  power  from  the  originating 
source  to  a  major  power  distribution  point.  These  forests  are  developed  In 
order  to  analyze  power  distribution.  Once  this  analysis  Is  performed*  these 
power  forests  are  cross-referenced  on  the  system  signal  forests  and  network 
trees  by  the  number  of  the  nodal  set  which  displays  the  power  distribution 
tree. 


Figure  A-2.  Pitch  Lamp  Drive  Circuitry  Network  Tree 


Ground  Forest.  A  ground  forest  traces  electrical  power  from  all  points  of 
connection  to  system  ground.  These  forests  are  developed  In  order  to  analyze 
power  returns.  Once  this  analysis  Is  performed*  these  forests  are  cross- 
referenced  to  the  system  signal  forests  as  required. 
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Figure  A-3.  Pitch  Lamp  Drive  Overview  Forest 


Signal  Forest.  A  signal  forest  traces  electrical  signal  flow  from  point  of 
origin  to  point  of  distribution.  These  forests  represent  the  electrical 
system  physical  continuities.  Functional  continuities  are  attained  through 
cross-referencing  to  other  signal  forests.  In  certain  cases,  both  physical 
and  functional  continuities  are  represented  in  the  same  forest.  The  content 
of  each  signal  forest  and  the  level  of  detail  are  functions  of  the  intended 
purpose  of  the  forest.  These  forests  can  be  combined  and  data  selectively 
omitted  when  the  purpose  is  FIP  logic  diagram  development.  No  data  are 
omitted  when  the  purpose  is  system  analysis. 

Key  Element.  Each  system  component  that  interfaces  with  the  environment  is 
known  as  a  key  element.  Examples  of  such  key  elements  are  lights,  meters, 
flags,  switches,  controllers,  and  sensors.  Each  of  these  key  elements  either 
influences  the  operation  of  the  system  or  is  Influenced  by  it.  Those  elements 
which  output  to  the  environment  (lights,  meters,  flags,  etc.)  are  normally  the 
prime  indicators  of  system  malfunctions.  Those  elements  which  input  from  the 
environment  to  the  system  (switches,  controllers,  sensors)  are  also  vital  in 
that  their  failures  to  perform  their  intended  functions  are  also  key  fault 
Indications. 

Reference  Designator.  Each  SCA  data  record  contains  at  least  one  reference 
designator  (REPbES).  The  purpose  of  the  REFDES  is  to  provide  the  computer 
with  exact  component  location  information  in  a  simple  alphanumeric  character 
string.  For  example,  the  first  four  characters  could  indicate  the  LRU,  the 
next  two  a  module  within  that  LRU,  and  the  the  next  two  a  printed  circuit 
board,  and  so  on. 

Functional  Pathing.  Functional  pathing  is  a  technique  in  which  the  data  base 
is  searched,  starting  at  a  key  element,  and  a  collection  of  linked  data 
records  is  obtained.  It  is  the  first  step  in  isolating  only  those  system 
continuities  relating  to  the  specified  key  element. 

Logic  Diagram.  The  logic  diagram  represents  the  sequential  and  conditional 
observation  and  testing  steps  required  to  Isolate  a  specific  malfunction. 

These  diagrams  are  developed  through  the  use  of  system  forests  and  network 
trees  and  lead  directly  to  the  development  of  FIPs. 


